//////////////////////////////
Code at 0x80000180 in RAM (interrupt handler?) jumps to
0x80075030, the code of which is stored at 0xB0075C30 (ROM address)
Word from RAM to be added to checksum is loaded by instruction at 0x80000114
Checksum stored at 0xB0000014 is verified at 0x80000238
Putting 0 at 0xB0000788 (ROM) nops the branch at 0x80000238 that sends the game
	into an infinite loop (when the checksum fails, anyway) (doesn't work)
Changing 0xB0000798 from 0x0411FFFF to 0x04110001 causes the infinite loop branch
	to branch where the code would normally go (works in Nemu)
The above doesn't work in Mupen++; recalculating the checksums does
Changing 0xB0075C64 to 0x37480000 should change the checksum without modifying the code behavior
This also screws up the checksum stored at 0xB0000010 which is checked by 0x8000022C
	New checksums for 10 and 14 are 0x6A7009EE and 0x27941788
	The original checksums, for reference, are 0x8A6009B6 and 0x94ACE150
	This hack
		0xB0000010 = 0x6A7009EE
		0xB0000014 = 0x27941788
		0xB0075C64 = 0x37480000
	Runs in Nemu, PJ 64 1.6 and Mupen64++ but causes bosses to not work (retarded plugin BS; see below for explanation)
		(Nemu eventually fails to run the game and ignores checksums anyway so testing in Nemu is pointless)
The upper bound of the checksum protected area is 0xB0101000
	(editing this or later does not affect the checksums but editing earlier bytes does)

~~~~~

Project 64 read of the checksum at 0x10 which,
if it and the address after are frozen
to be the usual values at the addresses 0x10 and 0x14 in the ROM,
will cause the game to allow proper play of bosses despite the above hack being applied:

100094B4 - 8B 50 10  - mov edx,[eax+10] - PC is 0xA4000040 when this is executed;
fixing the checksum just before this read fixes the issue

Further inspection indicates that this code goes through a list of checksum pairs for common games
and determines a value to associate with the game for use by the graphics plugin,
presumably to determine the game's requirements;
it appears the issue is not copy protection but rather plugin ignorance.

Forcing 0x10088C1C of the plugin dll's memory to have the value 0x26 resolves the issue
but it is undetermined where the heck the list of checksums/settings pairs is stored;
disassembling the graphics plugin being used showed different, garbled data to be loaded to the address
where the list normally is and the tool used for the disassembly
reported some kind of intentional mangling may have been done.
I'm starting to wonder if Jabo is a tool.

Mupen and Project 64 can be shown to share this behavior when sharing plugins,
further indicating it may be hidden within the plugin.
Why would you hardcode something that important?!

Relevant snippet from the list I can't seem to locate the source of:

B6 09 60 8A 50 E1 AC 94 26 00 00 00 00 00 00 00

~~~~~

Using MIPS_Func, from

http://dl.dropbox.com/u/336940/Hextator%27s%20Doc.7z

in the folder

Hextator's Doc/Development/Applications/Reverse Engineering/MIPS_Func

determined the following function is executed early enough in the game to hook a trainer by and that the function is located outside of the checksum protected region:

the file "Function Log.txt" was generated.

0000019C was the first hit, which was a poor choice for hooking a trainer.
00000197 was the next hit, which only had a single JAL instruction translated prior to execution but still appears to be a poor choice for hooking a trainer due to emulator issues (for example I watched the stack pointer be different values based solely on whether there was a breakpoint in the execution's flow).
000001DB isn't a good idea
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

//////////////////////////////
From EnHacklopedia:
Writing over the 4 bytes at 0x80000318 sets the highest address the game is allowed to write.
Reading the value at that address can be used to detect the expansion pak.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

//////////////////////////////
Last 8 kilobytes (0xB1FFE000 to 0xB2000000) of ROM are available
	0xFF padding actually begins at 0xB1FF6880
These regions appear to be free in RAM (WARNING: 0x00000000 NOPs in branch/jump delay slots not considered):
	0x800B5350 to 0x800B9B50
	0x800BD230 to 0x800C06B0
	0x800C7290 to 0x800C8D40
	0x800CAA30 to 0x800CC4E0
	0x800CD060 to 0x800D04E0
	0x800D1060 to 0x800D44E0
	0x800D5060 to 0x800D84E0
	0x800E0BE0 to 0x800E42E0
	0x800E8B60 to 0x800E94E0
	0x800E97C0 to 0x800F1320
	0x800F4960 to 0x800F5AF0
	0x800F5C00 to 0x800F6B00
	[many other regions were skipped]
	0x80110140 to 0x80135520 (!)
	0x8014D0F0 to 0x8015AD50 (!)
	[etc.]
	Although these regions haven't been confirmed, 9 RAM dumps within unique, common
	contexts of the game all had the regions clear or set to the same repeated value for all bytes
	Most tests with the trainer at these locations however result in crashes or other problems so giving up and using the expansion pak's memory is a better idea
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
